/// 采用发布配置自定义构建

/*
在 Rust 中 发布配置（release profiles）是预定义的、可定制的带有不同选项的配置，
他们允许开发者更灵活地控制代码编译的多种选项。每一个配置都彼此相互独立。

Cargo 有两个主要的配置：运行 cargo build 时采用的 dev 配置和运行 cargo build --release 的 release 配置。
dev 配置被定义为开发时的好的默认配置，release 配置则有着良好的发布构建的默认配置。

当项目的 Cargo.toml 文件中没有任何 [profile.*] 部分的时候，Cargo 会对每一个配置都采用默认设置。
通过在[profile.*]对应的部分中增加任何定制的配置，我们可以覆盖任意默认设置的子集。
*/

[profile.dev]
opt-level = 0

[profile.release]
opt-level = 3

/*
opt-level 设置控制 Rust 会对代码进行何种程度的优化。这个配置的值从 0 到 3。越高的优化级别需要更多的时间编译，
所以如果你在进行开发并经常编译，可能会希望在牺牲一些代码性能的情况下编译得快一些。
这就是为什么 dev 的 opt-level 默认为 0。当你准备发布时，花费更多时间在编译上则更好。只需要在发布模式编译一次，
而编译出来的程序则会运行很多次，所以发布模式用更长的编译时间换取运行更快的代码。
这正是为什么 release 配置的 opt-level 默认为 3。
*/


/// 将 crate 发布到 Crates.io
/*
我们曾经在项目中使用 crates.io 上的包作为依赖，不过你也可以通过发布自己的包来向别人分享代码。
crates.io 用来分发包的源代码，所以它主要托管开源代码。
Rust 和 Cargo 有一些帮助别人更方便找到和使用你发布的包的功能。我们将介绍一些这样的功能，接着讲到如何发布一个包。
*/
/// 编写有用的文档注释
/*
准确的包文档有助于其他用户理解如何以及何时使用他们，所以花一些时间编写文档是值得的。之前我们使用过两斜杠 // 注释 Rust 代码。
Rust 也有特定的用于文档的注释类型，通常被称为 文档注释（documentation comments），他们会生成 HTML 文档。
这些 HTML 展示公有 API 文档注释的内容，他们意在让对库感兴趣的开发者理解如何 使用 这个 crate，而不是它是如何被 实现 的。

文档注释使用三斜杠 /// 而不是两斜杆以支持 Markdown 标记来格式化文本。文档注释就位于需要文档的项的之前。
*/

/// Adds one to the number given.
///
/// # Examples
///
/// ```
/// let arg = 5;
/// let answer = my_crate::add_one(arg);
///
/// assert_eq!(6, answer);
/// ```
pub fn add_one(x: i32) -> i32 {
    x + 1
}
// 具体其他配置参考文档： https://rustwiki.org/zh-CN/book/ch14-02-publishing-to-crates-io.html

/// Cargo 工作空间
/*
我们构建一个包含二进制 crate 和库 crate 的包。你可能会发现，随着项目开发的深入，库 crate 持续增大，
而你希望将其进一步拆分成多个库 crate。对于这种情况，Cargo 提供了一个叫 工作空间（workspaces）的功能，
它可以帮助我们管理多个相关的协同开发的包。相当于maven项目构建文件的modules标签

├── Cargo.lock
├── Cargo.toml
├── add-one
│   ├── Cargo.toml
│   └── src
│       └── lib.rs
├── adder
│   ├── Cargo.toml
│   └── src
│       └── main.rs
└── target
 */
[workspace]
members = [
"adder",
"add-one",
]
/*
工作空间在顶级目录有一个 target 目录；adder 并没有自己的 target 目录。即使进入 adder 目录运行 cargo build，
构建结果也位于 add/target 而不是 add/adder/target。工作空间中的 crate 之间相互依赖。
如果每个 crate 有其自己的 target 目录，为了在自己的 target 目录中生成构建结果，
工作空间中的每一个 crate 都不得不相互重新编译其他 crate。通过共享一个 target 目录，
工作空间可以避免其他 crate 多余的重复构建。

现在工作空间中有了一个库 crate，让 adder 依赖库 crate add-one。首先需要在 adder/Cargo.toml 文件中增加 add-one 作为路径依赖：
[dependencies]
rand = "0.5.5"                              // 外部第三方 crate 依赖
add-one = { path = "../add-one" }           // 本地 crate 依赖
这样做就表明当前 crate 依赖于 add-one 这个 crate 并且引入了该依赖
*/